A request sent from a web client (such as a web browser) is received by a web server. The web server then passes the request to an application server which processes the request, calculates the results, and streams the results back to the web server for display. Web/application servers cache output as a function of the input (parameters in the request). These servers typically cache an entire page of data.
Data is cached so that the processing does not have to be repeated for every request for the same page of data. When caching is implemented, some processing is performed and the results are cached for some period of time. Any subsequent requests that match some criteria for the cached data result in the web server streaming the output that has been stored in the cache rather than to re-calculate it. In large applications, it is sometimes necessary to cache components contained within the page rather than the entire page. This allows a page to have components that expire at different times, such that only these components are recalculated for the next request for that page.
The Netscape Application Server, NAS, (also called KIVA Enterprise Server), of Netscape Corporation of Mountain View, Calif., has been used here to compute stream out the dynamic components of a Web page. In Kiva, component objects to stream data have been written using Kiva's AppLogic class. Kiva provides an application programming interface (API) that provides a set of programming instructions that accomplish a well-defined, modular task within the application. In order to process multiple components within a page of data, each component makes a new request to the application server. Each new request requires a new thread and generates all the objects to execute, which consumes valuable system resources. KIVA provides a caching technique to cache each request.
A disadvantage of using the Kiva Enterprise Server caching technique is that every new request needs to be sent to the application server. This results in a greater amount of overhead as there is a high cost associated with starting out a new request. Thus, if a given page contains five different components, the server will process this as six separate and full requests (the page plus the first components) and each request would carry with it the high cost of starting out a new request. Also in this solution, the new request which is being cached needs to be specially programmed to activate the caching. This becomes a maintenance problem as every object that uses caching must be examined, in order to modify it.